Designers/developers of integrated circuits variously referred to as ASIC's (Application Specific Integrated Circuits) or SoC's (System on a Chip) are faced with a problem. The current technology for design and development can handle either complexity or scale but not both. There are also further problems in developing product for enlarged markets.
SoC's are designed to meet the needs of specific applications or a range of specific applications. They have advantages over general purpose processors used for those applications. The advantages generally involve cost, size, power consumption and processing suited to the application. In some cases SoC's are the only way to fully meet application requirements.
In many cases, an SoC has been developed as the least common multiply of IPs in order to cover as many applications as possible. That has been considered as the solution for shorter time to market and less development cost. For example, an SoC with SATA, Ethernet, and PCIe can be developed for multiple applications, such as Network Attached Storage (NAS) or wireless router. Although PCIe will be disabled for NAS and SATA will be disabled for router, the time to market is shorter than developing two different SoC's.
With current technology, SoC's are relatively easy to develop if they have a relatively small numbers of cores or if the core interfaces are simple, all conform to the same set of standards and come from the same vendor (developer). Unfortunately, the market has driven SoC's to integrate large numbers of cores with complex interfaces that follow, to one extent or another, a number of different standards and come from a wide variety of vendors. Although, there are some tools to help SoC developers, the job of configuring the individual cores in such a way that they can optimally work together to create an SoC is largely manual. Configuring all the cores on an SoC for the best possible performance to accomplish the objective is called “orchestration”.
Furthermore, the orchestration of a particular SoC is typically focused on a single application. Even if 90% of the cores could be used for another related application, that SoC has to be a separate semiconductor with separate orchestration. This raises the cost of both SoC's because it reduces the potential economy of scale. Optimal leveraging of economies of scale is what can make semiconductors so cost effective.
Another consideration is that the orchestration is required to manage optimization across multiple perspectives, such as performance, power, thermal, and so on. The existing development methods typically handle single perspective optimization per SoC. For example, an SoC for server application may be tuned for performance, and an SoC for consumer application may be tuned for longer battery life. However, these perspectives are no longer independent where complexity and scale converges.
FIG. 1 is a block diagram illustrating an embodiment of a wireless router system built using IP cores. In the example shown, an available set of IP cores 100 includes a Gigabit Ethernet core 102, a USB2/USB3 core 104, a video/graphics controller core 106, an application processor core 108, a SATA controller core 110, and a WiFi radio core 112. Through a design process 114 the cores 102, 104, 108, and 112 are selected, configured, and inter-connected to provide and implement an integrated circuit design 120 for a wireless router. The cores 106 and 110 are not used in the design, in this example because their functionality is not required to be included in the wireless router to be built using design 120. Typically, the design process 114 is labor intensive and time consuming. Mutually compatible cores having desired features and performance characteristics must be identified from a variety of sources, each potentially using a different way to describe its various IP cores. Once cores have been selected, their respective configurations must be determined based on their respective attributes, and an integrated design incorporating the selected and configured cores generated, for example by one or more human operators using design tools that partly automate the process.
FIG. 2 is a block diagram illustrating an embodiment of a system built using IP cores. In the example shown, the system 200 has been built by connecting the cores 102, 104, 106, 108, 110, and 112 of FIG. 1 via a high speed interconnect 202. Each of the cores 102, 104, 106, 110, and 112 has an associated range of supported and/or required data rates as indicated in FIG. 2. In a typical prior art design process, a human designer must consider the respective supported and/or required rates and must select a design rate and/or other configuration data for the respective IP cores. In addition, different applications that might be run on application processor core 108 may require and/or imply different peak data rates, such that the application(s) to be supported by the system may have to be taken into consideration in selecting the other cores, the required (or available) capacity of the interconnect 202, and the respective rates at which the IP cores will be configured to operate. The frequency at which the application processor and/or other cores will operate may also have to be determined and set.
The internal structure of the Conductor in some embodiments is shown in FIG. 10.
The internal structure of the Orchestrator is shown in FIG. 11